Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Welcome @jasimmons!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @jasimmons. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Hey, @mattjmcnaughton , thanks! :)

Can you share a little more about the specific bug(s) that we're trying to solve? Is it that we are not respecting headers passed to HTTPGetAction.

That's part of it, yes. Also, though, lifecycle handlers always prepend a leading / in their path, which is different than the behavior of probers.

As an example, here's a pod:

apiVersion: v1
kind: Pod
metadata:
  name: sample-webserver
spec:
  containers:
    - name: webserver
      image: alpine:3
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo 'HTTP/1.1 204 No Content' | nc -l -p 80; done"]
      ports:
        - name: tcp-80
          containerPort: 80
          protocol: TCP
      readinessProbe:
        httpGet:
          path: /ready
          port: 80
          scheme: HTTP
          httpHeaders:
            - name: foo
              value: bar
      lifecycle:
        preStop:
          httpGet:
            path: /preStop
            port: 80
            scheme: HTTP
            httpHeaders:
              - name: foo
                value: bar

When applying this and viewing the logs of this pod, you can see the path is as-expected and HTTP headers are passed appropriately for the readinessProbe:

GET /ready HTTP/1.1
Host: 10.38.36.93:80
User-Agent: kube-probe/1.16
foo: bar
Accept-Encoding: gzip
Connection: close

However, when terminating this pod, the log shows that the path always has a / prepended, and the HTTP headers are not passed in the preStop hook:

GET //preStop HTTP/1.1
Host: 10.38.36.93:80
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip

Additionally, when you describe this diff as "normalizing", can you share more about what we are normalizing w.r.t? My initial thought was that other parts of k8s are using HttpDoer, so we would be unifying behavior in this respect. However, I don't see any existing mentions of HttpDoer.

The normalization here is the behavior of that of httpGet actions for probers and lifecycle handlers. My assumption is that probers do what is expected, but lifecycle handlers do not. "What is expected" in this context is the proper formatting of the URL (prepending a / if necessary, but not if not) and passing HTTP headers in the request.

The HttpDoer interface is replacing an HttpGetter to provide the same functionality but with the ability to accept HTTP headers. HttpGetter similarly was not used anywhere outside of this, so I'm certainly open to trying to find a new home for the interface.

Thanks for the feedback!

change lgtm, go ahead and squash down to the commits you want for merge and open a tracking issue for the two follow-ups (for the metric and the event)

change lgtm, go ahead and squash down to the commits you want for merge and open a tracking issue for the two follow-ups (for the metric and the event)

Happy to look over the metric once you have something ready.

I've squashed the changes down to two commits. No other changes were made since the last review.

The follow up issue is #113174.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: derekwaynecarr, jasimmons, liggitt, ohbus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/retest

@jasimmons: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

/test pull-kubernetes-e2e-gce-ubuntu-containerd

Updated release note with event and metric name added in #113175